The present invention relates generally to databases. More particularly, the present invention relates to trigger processing in active databases.
An active database is a database in which certain actions result in other actions being taken automatically by the database. An active database may be implemented using the well known database technique of triggers. A trigger defines an event, a condition, and an action. The database monitors itself for the occurrence of the event, at which time it checks the condition. If the condition is true, then the database performs the action automatically.
As an example of trigger processing, consider a database which stores employees and associated department numbers for each employee. If a database user submits a database command to delete a department number from the database, it is advantageous to have the database system automatically check to determine whether there are currently employees assigned to that department number. If there are, then the request to delete the department number should be rejected. In order to implement this functionality in a trigger, the trigger event being monitored would be the deletion of a department number, the condition would be whether there are currently any employee records which contain that department number, and the action would be to reject the database delete command.
As is well known, databases generally consist of stored data and a database management system (DBMS) which manages the stored data and which processes database commands. Currently, active database triggers are generally implemented at the DBMS level. Thus, each database system uses its own proprietary technique for implementing active database triggers. This implementation of triggers results in several problems. First, trigger implementation is not standard across different database platforms, and therefore it is difficult to port trigger facilities from one database system to another. Second, the adding of new trigger facilities requires modifications to the DBMS internal software, which can only be done by the database manufacturer. As a result, the implementation of trigger facilities locally by database administrators is not possible.
One technique used to locally implement trigger functionality is to monitor the database log file and initiate certain trigger processing when certain predetermined actions are detected in the log file. However, this technique requires knowledge of the DBMS proprietary log format which may not be available to system administrators. Another technique is the periodic polling of the state of the database to determine whether certain changes have been made. The problem with this technique is that it adds a substantial amount of overhead processing and is therefore expensive.
Another technique used to locally implement trigger functionality is the use of software plug-ins which are associated with database operations. However, such plug-ins are implemented as function calls within the database system itself, which results in several problems. First, a problem with a plug-in can result in a crash of the database system itself. Second, adding a new plug-in requires restarting the entire database system. Third, trigger portability is reduced because of the proprietary extension required to the database system.
Thus, there is a need for an improved technique for locally adding trigger processing to database systems.
In accordance with the present invention, trigger functionality is implemented at a trigger gateway which is independent of an associated database system. The trigger gateway receives database commands destined for the database system and processes triggers associated with the database commands. Where appropriate, the trigger gateway forwards the database commands to the database system for processing of those commands in a conventional manner. The use of a trigger gateway to implement trigger functionality allows the use of standard database commands and requires no modification to the database system. In fact, the database system may have no knowledge that trigger functionality is being provided by the trigger gateway.
In accordance with one aspect of the invention, trigger actions are executed by a remote trigger action server in response to a trigger execution request transmitted by the trigger gateway. The use of a trigger action server to execute trigger actions is advantageous because it allows for the updating of instructions implementing the trigger actions without interrupting the operation of the database or the trigger gateway. Alternatively, the trigger actions could be executed in the trigger gateway itself.
In accordance with security aspects of the invention, trigger actions will not be executed if such execution would result in a security breach of the security policy of the database system. Such security aspects are implemented by having the trigger gateway formulate and then perform a database query using the security authorization of a trigger author prior to executing a trigger action. If this query results in an authorization error, then the trigger action will not be executed.
In accordance with another aspect of the invention, a new type of trigger is implemented which results in the execution of a trigger action as the result of the failure of a database command. Thus, if a database command results in an error during database processing, an xe2x80x9cafter failedxe2x80x9d trigger may be processed which will result in the execution of some trigger action specifically chosen to be executed after a failed database command.
In accordance with yet another aspect of the invention, infinite loops are prevented using novel trigger processing techniques.
These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings.